home *** CD-ROM | disk | FTP | other *** search
/ Hackers Underworld 2: Forbidden Knowledge / Hackers Underworld 2: Forbidden Knowledge.iso / VIRUS / CRCREVUE < prev    next >
Text File  |  1990-12-18  |  56KB  |  1,575 lines
  1.        Comparison: Products to Detect Changes to Programs
  2.  
  3.                Prepared by David J. Stang, Ph.D.
  4.                      and (c) 1990, 1991 by
  5.            the National Computer Security Association
  6.               Suite 309, 4401-A Connecticut Ave NW
  7.                        Washington DC 20008
  8.                        Voice: 202-364-8252
  9.                         BBS: 202-364-1304
  10.  
  11. This document may be freely distributed, but may not be altered
  12. in any way.
  13.  
  14. This is a review of some of those checksum or CRC comparison
  15. programs. In it, I make an effort to concisely describe the 
  16. merits of this class of products, and then to help
  17. you in selecting a product from their ranks.
  18.  
  19. There is a difference between checksum algorithms and CRC --
  20. cyclic redundancy check -- algorithms. The latter usually uses a
  21. table, and is usually a bit slower than the former. Despite the
  22. differences, many authors seem to use the words
  23. interchangeably, and we will continue the sloppy practice in this
  24. chapter.
  25.  
  26. Each file has a unique  fingerprint in the form of a checksum
  27. or CRC. Changes in any character within the file likely change
  28. the checksum or CRC. If a file's original CRC is known --
  29. perhaps recorded in a file elsewhere -- and its current CRC is
  30. known, the two values can be compared. Any difference indicates
  31. that the file has been changed, and offers reason to investigate
  32. further. For example, DELOUSE allows you to build a list of
  33. critical system files that are normally subject to attack, and
  34. check them periodically for changes.
  35.  
  36. If a program's size is changed, it must be concluded that some
  37. modification has occured to the file. If the size has not changed,
  38. some modification is still possible. A file that contains the simple
  39. message  Hi Mom! could be modified so that it contained the
  40. message  Hi Dad!, and it would not show any change in size.
  41.  
  42. A much tougher test of whether a file has been modified is to
  43. compute the  checksum or CRC cyclic redundancy check. At
  44. this writing, there are no viruses able to modify a file without
  45. modifying the file's CRC. Thus any checksum checker will work
  46. just fine in catching viruses, providing that you use it to
  47. establish checksums before a virus has modified your files.
  48.  
  49. How is the checksum computed? Simply adding the values of all
  50. the characters in the file is not enough, as a file containing just
  51. "AE" would produce the same result as a file with just "EA".
  52. Rather, the first byte of a file is read, and an algorithm applied
  53. to it. This algorithm does something to the value of the byte,
  54. such as rotating the bits a certain number of times, and logically
  55. ANDING or ORING the bits to something else. The result of
  56. that algorithm is then applied to the next byte of the file. The
  57. process is repeated until the final byte is reached, and the
  58. remainder is recorded. During this process, different algorithms
  59. might be used for different portions of the code being processed.
  60. With most procedures, a small file produces a checksum value of
  61. the same size as a large file.
  62.  
  63. Is there such as thing as "the" CRC value? No. The algorithm
  64. used defines the result. There are two popular algorithms in use:
  65. a standard CCITT CRC and a popular XMODEM CRC. Consider
  66. COMMAND.COM for DOS 3.3 dated 2/2/88 and taking 25308
  67. bytes. Here are some of the checksums produced for this file by
  68. various programs. SSCRC and Validate (method 1) use the
  69. CCITT standard. All others in the list use some other approach.
  70.  
  71.     o    BSearch, 16-bit CRC - 13369 (3439 h)
  72.     o    BSearch, CRCTT - 10994 (2AC0 h)
  73.     o    CHKSUM - 20011 (4E2B h)
  74.     o    CRCDOS - 59676 (E91C h)
  75.     o    Delouse, method 1 - 1073916 (1062FC h)
  76.     o    Delouse, method 2 - 1067428 (1049A4 h)
  77.     o    Delouse, method 3 - 1048666 (10005A h)
  78.     o    The Detective, CRC 1 - 26939 (693B h)
  79.     o    The Detective, CRC 2 - 54914 (D682 h)
  80.     o    Module Integrity Check - 24922 (615A)
  81.     o    SSCRC - 52167 (CBC7 h) 
  82.     o    Validate, method 1 - 52167 (CBC7 h)
  83.     o    Validate, method 2 - 4024 (0FB8 h)
  84.     o    VCheck - 2141344 (0020ACA0 h)
  85.  
  86.  
  87.  
  88.                        WHY DETECT CHANGES?
  89.  
  90.  
  91.  
  92. There are several good reasons.
  93.  
  94.     o  Viruses have great difficulty infecting your machine
  95.          without making some change in it. To detect a change
  96.          is to begin the process of detecting a virus. Although
  97.          some are concerned that a change-detecting program
  98.          cannot prove there isn't already a virus in your
  99.          computer, the fact is that you needn't worry about this.
  100.          If you infect your computer with a dozen viruses, then
  101.          measure its state, one of these viruses will change that
  102.          state in the next hour or so; a remeasurement
  103.          establishes that something is afoot.
  104.  
  105.     o  Occasionally things go wrong with computer hardware
  106.          and software. You run CHKDSK and discover a
  107.          number of lost clusters in a number of lost chains. You
  108.          scrap these clusters, but wonder what files you've lost.
  109.          A proper change-detection program will give you a list
  110.          of files deleted since your last run. You can then
  111.          restore them from your backups.
  112.  
  113.     o  In many organizations, we only want to permit the use
  114.          of "authorized software." Using a proper
  115.          change-detection program, you can establish what
  116.          software was added to the machine since your last run.
  117.          Any "extra" software will quickly come to your
  118.          attention.
  119.  
  120.  
  121.  
  122.                   CAN A VIRUS BEAT THE SYSTEM?
  123.  
  124.  
  125. The answer may be yes. You need to know how, so it doesn't
  126. happen to you. The defeat can come at the hands of a
  127. CRC-aware virus (none exists yet) or at the hands of a stealth
  128. virus (there are several now).
  129.  
  130.  
  131.  
  132.                         CRC-AWARE VIRUSES
  133.  
  134.  
  135. In theory, a virus could be written that would compute a file's
  136. CRC, add itself to the file, then replace additional characters
  137. from the file until the new CRC was the same as the old one.
  138. Such a virus would escape the attention of many checksum
  139. checkers.
  140.  
  141. Programs could catch such a virus by using an  incremental
  142. cyclic redundancy check approach. In this approach, files are
  143. dissected into randomly-sized blocks of data, using dynamic
  144. block size allocations that allow files as small as one byte to be
  145. accurately checked. CHECKUP uses this approach. It scans and
  146. compares every byte of the target files on a block-by-block basis.
  147. If the recorded file sizes, any of the block CRC comparisons, or
  148. the CRC totals do not match, CHECKUP alerts users that the
  149. target files have been altered.
  150.  
  151. Another approach to the problem is to compute the check in two
  152. different ways. For example, if both a checksum and a file size
  153. were to be calculated and recorded for later comparison, it is
  154. unlikely that a virus could be modified without mismatching on
  155. one of the comparisons. Or if checksums were to be calculated
  156. using two different algorithms, the virus would again likely fail
  157. to fool both techniques.
  158.  
  159. Thus if some future virus were to compute checksums prior to
  160. infections, pad their viral code with characters that maintain
  161. checksum integrity and then infect, CHECKUP could catch it.
  162.  
  163.  
  164.  
  165.                          STEALTH VIRUSES
  166.  
  167.  
  168. A stealth virus is able to defeat a checksum program if it loads
  169. into memory before the checksum program runs. The stealth
  170. virus can then detect the checksum program as it attempts to
  171. read each program on the disk, and before letting the checksum
  172. program see the file it is trying to read, extracting the virus
  173. from it. After the checksum program is satisfied that there is no
  174. virus in the file, the virus in memory can re-insert it into the
  175. file just checked.
  176.  
  177. Such a problem can be easily avoided: simply boot the system
  178. from an uninfected floppy, then run your checksum program
  179. from it.
  180.  
  181. In the tables presented here, space has been provided for you to
  182. rate an additional product.
  183.  
  184.  
  185.  
  186.                        PRODUCT COMPARISONS
  187.  
  188.  
  189.  
  190.  
  191.                            EASE OF USE
  192.  
  193.  
  194. Conducting these evaluations was not easy. In the table below, I
  195. record my joy or frustration in trying to master the program.
  196.  
  197.     Alert
  198.  
  199.